GH-36411: [Python] Use scikit-build-core as build backend for PyArrow and get rid of setup.py by raulcd · Pull Request #49259 · apache/arrow

raulcd · 2026-02-12T14:43:07Z

Rationale for this change

Move our PyArrow build backend from setuptools and a custom setup.py to scikit-build-core which is just build backend for CMake related projects.

What changes are included in this PR?

Move from setuptools to scikit-build-core and remove PyArrow setup.py. Update some of the build requirements and minor fixes.
A custom build backend has been also been created in order to wrap scikit-build-core in order to fix problems on License files for monorepos.
pyproject.toml metadata validation expects license files to exist before exercising the build backend that's why we create symlinks. Our thin build backend will just make those symlinks hard-links in order for license and notice files to contain the contents and be added as part of the sdist.

Remove flags that are not used anymore (were only part of setup.py) and documented and validated how the same flags have to be used now.

Are these changes tested?

Yes all Python CI tests, wheels and sdist are successful.

Are there any user-facing changes?

Yes, users building PyArrow will now require the new build dependencies to exercise the build and depending on the flags used they might require to use the new documented way of using those flags.

GitHub Issue: [Python] Improve the pyarrow build system #36411

raulcd · 2026-02-12T16:36:22Z

@github-actions crossbow submit -g python

raulcd · 2026-02-12T17:21:34Z

@github-actions crossbow submit wheel-*-cp313-cp313-amd64

raulcd · 2026-02-13T09:20:41Z

@github-actions crossbow submit wheel-windows-cp313-cp313-amd64

github-actions · 2026-02-13T09:23:00Z

Revision: 166ff63

Submitted crossbow builds: ursacomputing/crossbow @ actions-f1bbdf4eaa

Task	Status
wheel-windows-cp313-cp313-amd64

raulcd · 2026-02-13T13:56:22Z

@github-actions crossbow submit wheel-windows-cp313-cp313-amd64

github-actions · 2026-02-13T13:58:35Z

Revision: 36fefd4

Submitted crossbow builds: ursacomputing/crossbow @ actions-bd811d95ea

Task	Status
wheel-windows-cp313-cp313-amd64

raulcd · 2026-02-16T11:11:05Z

@github-actions crossbow submit -g python -g wheel

raulcd · 2026-02-16T11:18:19Z

@github-actions crossbow submit python-sdist

github-actions · 2026-02-16T11:20:28Z

Revision: c518c90

Submitted crossbow builds: ursacomputing/crossbow @ actions-ea249e92ce

Task	Status
python-sdist

raulcd · 2026-02-17T10:56:00Z

@github-actions crossbow submit python-sdist

github-actions · 2026-02-17T10:58:07Z

Revision: 131e2c0

Submitted crossbow builds: ursacomputing/crossbow @ actions-1c58e78aff

Task	Status
python-sdist

raulcd · 2026-02-17T12:00:40Z

@github-actions crossbow submit python-sdist

github-actions · 2026-02-17T12:02:55Z

Revision: 30e04be

Submitted crossbow builds: ursacomputing/crossbow @ actions-3179f97956

Task	Status
python-sdist

raulcd · 2026-02-17T13:27:27Z

@github-actions crossbow submit -g python -g wheel

raulcd · 2026-02-17T18:08:23Z

@github-actions crossbow submit wheel-windows-cp313-cp313-amd64

github-actions · 2026-02-17T18:10:35Z

Revision: 5606749

Submitted crossbow builds: ursacomputing/crossbow @ actions-3c4293e220

Task	Status
wheel-windows-cp313-cp313-amd64

raulcd · 2026-02-19T12:18:23Z

@pitrou @WillAyd I think this is ready for a first round of reviews! All tests are green now.

WillAyd

Nice work - some small comments but generally this lgtm

docs/source/developers/python/building.rst

WillAyd · 2026-02-21T14:55:07Z

python/_build_backend/__init__.py

+    try:
+        yield
+    finally:
+        if sys.platform != "win32":


So these edits are made to the source tree directly right? No way to do this in an isolated build location?

I am unsure how we could manage those. We want to do non isolated builds to build against specific numpy/pandas versions, mandating isolated builds creates complexity on environments and dependency management. If we try to copy ourselves on a different location to build we are also creating a bunch of complexity for a really simple thing, having licenses copied! Do you have any suggestions on what I could try?
To be fair I've found the whole licenses / notice and how build backends manages them to be too tight and inflexible leaving cases like ours on a difficult spot. I have been thinking on just copying the files but maintenance is a burden just for keeping them in sync. Maybe we should copy them and have a CI check that validates they are in-sinc?
I feel like a really simple build backend that just copies the data, either by moving soft-links to hard links or, in the case of Windows, copying the files is the simplest solution.

Yea I agree with your overall sentiment - sadly its a lot of effort to maintain these two files :-)

I think the meson-python approach was pretty good, where a dist script copied these into the source distribution at the time it was being made. I'm wondering if scikit-build-core has a similar hook

From what I understand from scikit-build-core when building sdist we can't use an out of source tree. Basically the sdist is copying the files that are under Path() (.):
https://github.com/scikit-build/scikit-build-core/blob/49b26c49fb4bc2a94177e4ef27c79e6389375710/src/scikit_build_core/build/sdist.py#L153-L161

There's no config setting where we could use an out of source sdist where we could copy files.

Have you raised the issue on the scikit-build-core issue tracker?

I have just asked about it:

Generate sdist out of the source tree scikit-build/scikit-build-core#1237

…her we use build or pip

raulcd · 2026-02-24T11:25:10Z

@github-actions crossbow submit -g python -g wheel

github-actions · 2026-02-24T11:29:14Z

Revision: 0ada5d9

Submitted crossbow builds: ursacomputing/crossbow @ actions-5f312d0d53

Task	Status
example-python-minimal-build-fedora-conda
example-python-minimal-build-ubuntu-venv
python-sdist
test-conda-python-3.10
test-conda-python-3.10-hdfs-2.9.2
test-conda-python-3.10-hdfs-3.2.1
test-conda-python-3.10-pandas-1.3.4-numpy-1.21.2
test-conda-python-3.11
test-conda-python-3.11-dask-latest
test-conda-python-3.11-dask-upstream_devel
test-conda-python-3.11-hypothesis
test-conda-python-3.11-pandas-latest-numpy-latest
test-conda-python-3.11-spark-master
test-conda-python-3.12
test-conda-python-3.12-cpython-debug
test-conda-python-3.12-pandas-latest-numpy-1.26
test-conda-python-3.12-pandas-latest-numpy-latest
test-conda-python-3.13
test-conda-python-3.13-pandas-nightly-numpy-nightly
test-conda-python-3.13-pandas-upstream_devel-numpy-nightly
test-conda-python-3.14
test-conda-python-emscripten
test-debian-13-python-3-amd64
test-debian-13-python-3-i386
test-fedora-42-python-3
test-ubuntu-22.04-python-3
test-ubuntu-22.04-python-313-freethreading
test-ubuntu-24.04-python-3
wheel-macos-monterey-cp310-cp310-amd64
wheel-macos-monterey-cp310-cp310-arm64
wheel-macos-monterey-cp311-cp311-amd64
wheel-macos-monterey-cp311-cp311-arm64
wheel-macos-monterey-cp312-cp312-amd64
wheel-macos-monterey-cp312-cp312-arm64
wheel-macos-monterey-cp313-cp313-amd64
wheel-macos-monterey-cp313-cp313-arm64
wheel-macos-monterey-cp313-cp313t-amd64
wheel-macos-monterey-cp313-cp313t-arm64
wheel-macos-monterey-cp314-cp314-amd64
wheel-macos-monterey-cp314-cp314-arm64
wheel-macos-monterey-cp314-cp314t-amd64
wheel-macos-monterey-cp314-cp314t-arm64
wheel-manylinux-2-28-cp310-cp310-amd64
wheel-manylinux-2-28-cp310-cp310-arm64
wheel-manylinux-2-28-cp311-cp311-amd64
wheel-manylinux-2-28-cp311-cp311-arm64
wheel-manylinux-2-28-cp312-cp312-amd64
wheel-manylinux-2-28-cp312-cp312-arm64
wheel-manylinux-2-28-cp313-cp313-amd64
wheel-manylinux-2-28-cp313-cp313-arm64
wheel-manylinux-2-28-cp313-cp313t-amd64
wheel-manylinux-2-28-cp313-cp313t-arm64
wheel-manylinux-2-28-cp314-cp314-amd64
wheel-manylinux-2-28-cp314-cp314-arm64
wheel-manylinux-2-28-cp314-cp314t-amd64
wheel-manylinux-2-28-cp314-cp314t-arm64
wheel-musllinux-1-2-cp310-cp310-amd64
wheel-musllinux-1-2-cp310-cp310-arm64
wheel-musllinux-1-2-cp311-cp311-amd64
wheel-musllinux-1-2-cp311-cp311-arm64
wheel-musllinux-1-2-cp312-cp312-amd64
wheel-musllinux-1-2-cp312-cp312-arm64
wheel-musllinux-1-2-cp313-cp313-amd64
wheel-musllinux-1-2-cp313-cp313-arm64
wheel-musllinux-1-2-cp313-cp313t-amd64
wheel-musllinux-1-2-cp313-cp313t-arm64
wheel-musllinux-1-2-cp314-cp314-amd64
wheel-musllinux-1-2-cp314-cp314-arm64
wheel-musllinux-1-2-cp314-cp314t-amd64
wheel-musllinux-1-2-cp314-cp314t-arm64
wheel-windows-cp310-cp310-amd64
wheel-windows-cp311-cp311-amd64
wheel-windows-cp312-cp312-amd64
wheel-windows-cp313-cp313-amd64
wheel-windows-cp313-cp313t-amd64
wheel-windows-cp314-cp314-amd64
wheel-windows-cp314-cp314t-amd64

pitrou · 2026-02-24T12:13:45Z

.github/workflows/dev.yml

        run: |
          gem install test-unit openssl
-          pip install "cython>=3.1" setuptools pytest requests setuptools-scm
+          pip install build "cython>=3.1" pytest requests scikit-build-core setuptools-scm


Can we rely on pyproject.toml for build dependencies at some point?

This is something that we are already facing (not strictly related to this PR). I've opened an enhancement for it:

[Python] Investigate whether we can rely on pyproject.toml for build dependencies #49398

pitrou · 2026-02-24T12:14:25Z

ci/scripts/python_build.bat

-set PYARROW_BUILD_TYPE=%CMAKE_BUILD_TYPE%
-set PYARROW_BUILD_VERBOSE=1
 set PYARROW_BUNDLE_ARROW_CPP=ON
-set PYARROW_CMAKE_GENERATOR=%CMAKE_GENERATOR%


Does scikit-build-core pick up the CMAKE_xxx environment variables automatically?

Based on other changes you did, it doesn't seem it does?

It doesn't pick the PYARROW_CMAKE_xxx (like PYARROW_CMAKE_OPTIONS) but it does with the standard CMAKE_xxx for example I've tested CMAKE_BUILD_PARALLEL_LEVEL both 1 and 16 and if I use -C build.verbose=true I can see Run Build Command(s): /usr/bin/ninja -v -j 1 or Run Build Command(s): /usr/bin/ninja -v -j 16 respectively.
As per CMAKE_BUILD_TYPE this is something to do with the multi-config generator we should rely on -C cmake.build-type="${CMAKE_BUILD_TYPE:-Debug} so scikit-build-core will either set CMAKE_BUILD_TYPE or pass --config on build

python/_build_backend/__init__.py

pitrou · 2026-02-24T13:16:48Z

python/_build_backend/__init__.py

+    try:
+        yield
+    finally:
+        if sys.platform != "win32":


Have you raised the issue on the scikit-build-core issue tracker?

pitrou · 2026-02-24T13:19:29Z

python/CMakeLists.txt

+  # as it's the most common build type for users building from source.
+  # This is mainly relevant for our Windows wheels, which are built with
+  # Visual Studio and thus use a multi-config generator with Release.
+  # As a note this is only to populate config_internal.h.cmake.


Hmm, it's not possible to populate config_internal.h.cmake separately for each config?

I have no idea how to do that with a multi-config generator because this would have to be done at build time not at config time.
I guess we could stop using configure_file for the multi-config case, drop config_internal.h.cmake and create a new file at build time that just generates the full file?
@kou do you have any idea what we could do here?

BTW this is something that is not really working today for multi-config generators because if we configure using CMAKE_BUILD_TYPE (will only populate the file, no effect on the real build type) but we build with --config using a different build type the result would be wrong.

pitrou · 2026-02-24T13:21:27Z

python/pyproject.toml

-pyarrow = ["*.pxd", "*.pyi", "*.pyx", "includes/*.pxd", "py.typed"]
+[tool.scikit-build.cmake.define]
+PYARROW_BUNDLE_ARROW_CPP = {env = "PYARROW_BUNDLE_ARROW_CPP", default = "OFF"}
+PYARROW_BUNDLE_CYTHON_CPP = {env = "PYARROW_BUNDLE_CYTHON_CPP", default = "OFF"}


Did you check that those were actually bundled in the wheels?

I did not but I have now 😄

PYARROW_BUNDLE_ARROW_CPP works. Building a wheel with PYARROW_BUNDLE_ARROW_CPP=OFF:

$ ls -lrth dist/pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl -rw-rw-r-- 1 raulcd raulcd 6.9M Feb 26 13:25 dist/pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl $ cd dist $ unzip pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl $ find . -iname libarrow* ./pyarrow/libarrow_python_flight.so.2400 ./pyarrow/libarrow_python.so ./pyarrow/includes/libarrow_substrait.pxd ./pyarrow/includes/libarrow_feather.pxd ./pyarrow/includes/libarrow_acero.pxd ./pyarrow/includes/libarrow_python.pxd ./pyarrow/includes/libarrow_dataset.pxd ./pyarrow/includes/libarrow_dataset_parquet.pxd ./pyarrow/includes/libarrow_fs.pxd ./pyarrow/includes/libarrow.pxd ./pyarrow/includes/libarrow_cuda.pxd ./pyarrow/includes/libarrow_flight.pxd ./pyarrow/libarrow_python_flight.so ./pyarrow/libarrow_python_flight.so.2400.0.0 ./pyarrow/libarrow_python.so.2400.0.0 ./pyarrow/libarrow_python.so.2400

with PYARROW_BUNDLE_ARROW_CPP=ON:

$ ls -lrth pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl -rw-rw-r-- 1 raulcd raulcd 162M Feb 26 13:34 pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl # unzip $ find . -iname libarrow* ./pyarrow/libarrow.so.2400 ./pyarrow/libarrow_acero.so.2400 ./pyarrow/libarrow_python_flight.so.2400 ./pyarrow/libarrow_compute.so.2400 ./pyarrow/libarrow_python.so ./pyarrow/libarrow_flight.so.2400 ./pyarrow/includes/libarrow_substrait.pxd ./pyarrow/includes/libarrow_feather.pxd ./pyarrow/includes/libarrow_acero.pxd ./pyarrow/includes/libarrow_python.pxd ./pyarrow/includes/libarrow_dataset.pxd ./pyarrow/includes/libarrow_dataset_parquet.pxd ./pyarrow/includes/libarrow_fs.pxd ./pyarrow/includes/libarrow.pxd ./pyarrow/includes/libarrow_cuda.pxd ./pyarrow/includes/libarrow_flight.pxd ./pyarrow/libarrow_python_flight.so ./pyarrow/libarrow_dataset.so.2400 ./pyarrow/libarrow_python_flight.so.2400.0.0 ./pyarrow/libarrow_python.so.2400.0.0 ./pyarrow/libarrow_python.so.2400

PYARROW_BUNDLE_CYTHON_CPP also works (See the cpp files). Building a wheel with PYARROW_BUNDLE_CYTHON_CPP=OFF:

Archive: pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl inflating: pyarrow/__init__.pxd inflating: pyarrow/__init__.py inflating: pyarrow/_acero.cpython-313-x86_64-linux-gnu.so inflating: pyarrow/_acero.pxd inflating: pyarrow/_acero.pyx inflating: pyarrow/_azurefs.pyx inflating: pyarrow/_compute.cpython-313-x86_64-linux-gnu.so inflating: pyarrow/_compute.pxd inflating: pyarrow/_compute.pyx inflating: pyarrow/_compute_docstrings.py inflating: pyarrow/_csv.cpython-313-x86_64-linux-gnu.so inflating: pyarrow/_csv.pxd inflating: pyarrow/_csv.pyx inflating: pyarrow/_cuda.pxd inflating: pyarrow/_cuda.pyx inflating: pyarrow/_dataset.cpython-313-x86_64-linux-gnu.so inflating: pyarrow/_dataset.pxd inflating: pyarrow/_dataset.pyx inflating: pyarrow/_dataset_orc.pyx inflating: pyarrow/_dataset_parquet.pxd inflating: pyarrow/_dataset_parquet.pyx inflating: pyarrow/_dataset_parquet_encryption.pyx ... $ ls -lrth dist/pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl -rw-rw-r-- 1 raulcd raulcd 6.9M Feb 26 13:55 dist/pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl

with PYARROW_BUNDLE_CYTHON_CPP=ON:

inflating: pyarrow/_acero.cpp inflating: pyarrow/_acero.cpython-313-x86_64-linux-gnu.so inflating: pyarrow/_acero.pxd inflating: pyarrow/_acero.pyx inflating: pyarrow/_azurefs.pyx inflating: pyarrow/_compute.cpp inflating: pyarrow/_compute.cpython-313-x86_64-linux-gnu.so inflating: pyarrow/_compute.pxd inflating: pyarrow/_compute.pyx inflating: pyarrow/_compute_docstrings.py inflating: pyarrow/_csv.cpp inflating: pyarrow/_csv.cpython-313-x86_64-linux-gnu.so inflating: pyarrow/_csv.pxd inflating: pyarrow/_csv.pyx inflating: pyarrow/_cuda.pxd inflating: pyarrow/_cuda.pyx inflating: pyarrow/_dataset.cpp inflating: pyarrow/_dataset.cpython-313-x86_64-linux-gnu.so ... $ ls -lrth dist/pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl -rw-rw-r-- 1 raulcd raulcd 11M Feb 26 14:26 dist/pyarrow-24.0.0.dev164+g0ada5d92a-cp313-cp313-linux_x86_64.whl # unzip

pitrou · 2026-02-24T13:23:02Z

python/pyproject.toml

+[tool.scikit-build.cmake.define]
+PYARROW_BUNDLE_ARROW_CPP = {env = "PYARROW_BUNDLE_ARROW_CPP", default = "OFF"}
+PYARROW_BUNDLE_CYTHON_CPP = {env = "PYARROW_BUNDLE_CYTHON_CPP", default = "OFF"}
+PYARROW_GENERATE_COVERAGE = {env = "PYARROW_GENERATE_COVERAGE", default = "OFF"}


At some point we should check whether this flag still works. Eons ago it was used to generate codecov reports, but we ditched all the corresponding scripting that had to merge coverage files generated during the C++ test suite and the Python test suite.

Can you open an issue for that?

Created:

[Python] Validate PYARROW_GENERATE_COVERAGE works as expected #49397

raulcd · 2026-02-26T14:27:27Z

@github-actions crossbow submit wheel*-cp313-* python-sdist

github-actions · 2026-02-26T14:30:10Z

Revision: 05953fa

Submitted crossbow builds: ursacomputing/crossbow @ actions-0bd37a6444

Task	Status
python-sdist
wheel-macos-monterey-cp313-cp313-amd64
wheel-macos-monterey-cp313-cp313-arm64
wheel-macos-monterey-cp313-cp313t-amd64
wheel-macos-monterey-cp313-cp313t-arm64
wheel-manylinux-2-28-cp313-cp313-amd64
wheel-manylinux-2-28-cp313-cp313-arm64
wheel-manylinux-2-28-cp313-cp313t-amd64
wheel-manylinux-2-28-cp313-cp313t-arm64
wheel-musllinux-1-2-cp313-cp313-amd64
wheel-musllinux-1-2-cp313-cp313-arm64
wheel-musllinux-1-2-cp313-cp313t-amd64
wheel-musllinux-1-2-cp313-cp313t-arm64
wheel-windows-cp313-cp313-amd64
wheel-windows-cp313-cp313t-amd64

raulcd · 2026-02-26T17:49:15Z

@github-actions crossbow submit wheel-windows-cp313-*

github-actions · 2026-02-26T17:51:31Z

Revision: 5b96076

Submitted crossbow builds: ursacomputing/crossbow @ actions-51187e0471

Task	Status
wheel-windows-cp313-cp313-amd64
wheel-windows-cp313-cp313t-amd64

raulcd requested review from AlenkaF and rok as code owners February 12, 2026 14:43

raulcd marked this pull request as draft February 12, 2026 14:43

This comment was marked as off-topic.

Sign in to view

github-actions bot added Component: Python awaiting committer review Awaiting committer review labels Feb 12, 2026

This comment was marked as outdated.

Sign in to view

raulcd mentioned this pull request Feb 16, 2026

[Python] Improve the pyarrow build system #36411

Open

This comment was marked as outdated.

Sign in to view

raulcd changed the title ~~POC: [Python] Testing scikit-build-core as build backend for PyArrow~~ GH-36411: [Python] Use scikit-build-core as build backend for PyArrow and get rid of setup.py Feb 17, 2026

github-actions bot added the Component: Documentation label Feb 18, 2026

POC: [Python] Testing scikit-build-core as build backend for PyArrow

9fe6b0e

rok mentioned this pull request Feb 20, 2026

Reintroduce docstring injection rok/arrow#49

Closed

WillAyd reviewed Feb 21, 2026

View reviewed changes

rok mentioned this pull request Feb 22, 2026

GH-49273: [Python] Move stub docstring script to _build_utils with gr… #49357

Open

github-actions bot added awaiting changes Awaiting changes and removed awaiting committer review Awaiting committer review labels Feb 23, 2026

Use -C instead of --config-setting or --config-settings based on whet…

0ada5d9

…her we use build or pip

github-actions bot added awaiting change review Awaiting change review awaiting changes Awaiting changes and removed awaiting changes Awaiting changes awaiting change review Awaiting change review labels Feb 24, 2026

pitrou reviewed Feb 24, 2026

View reviewed changes

Simplify copy licenses to be the same in all platforms

05953fa

github-actions bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Feb 26, 2026

github-actions bot added awaiting changes Awaiting changes and removed awaiting change review Awaiting change review labels Feb 26, 2026

Do not try to regenerate symlinks on Windows as it just fails

5b96076

github-actions bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Feb 26, 2026

Conversation

raulcd commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

This comment was marked as off-topic.

raulcd commented Feb 12, 2026

Uh oh!

This comment was marked as outdated.

raulcd commented Feb 12, 2026

Uh oh!

This comment was marked as outdated.

raulcd commented Feb 13, 2026

Uh oh!

github-actions bot commented Feb 13, 2026

Uh oh!

raulcd commented Feb 13, 2026

Uh oh!

github-actions bot commented Feb 13, 2026

Uh oh!

raulcd commented Feb 16, 2026

Uh oh!

This comment was marked as outdated.

raulcd commented Feb 16, 2026

Uh oh!

github-actions bot commented Feb 16, 2026

Uh oh!

raulcd commented Feb 17, 2026

Uh oh!

github-actions bot commented Feb 17, 2026

Uh oh!

raulcd commented Feb 17, 2026

Uh oh!

github-actions bot commented Feb 17, 2026

Uh oh!

raulcd commented Feb 17, 2026

Uh oh!

This comment was marked as outdated.

raulcd commented Feb 17, 2026

Uh oh!

github-actions bot commented Feb 17, 2026

Uh oh!

raulcd commented Feb 19, 2026

Uh oh!

WillAyd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raulcd commented Feb 24, 2026

Uh oh!

github-actions bot commented Feb 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raulcd commented Feb 12, 2026 •

edited

Loading